home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0033-Object Ordering (co-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  1.9 KB  |  39 lines  |  [TEXT/GEOL]
  1. Item    5666678                         12-June-89        18:58
  2.  
  3. From:   D2605                           Xanadu Operating,Marc Stiegler, PRT
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Object Ordering (comparing)
  8.  
  9. Alan, Chuck and John,
  10.  
  11.    I'm going to throw in my 2 bits on object ordering.  The idea of an ordering
  12. operation (not EQ, or EQUAL, to use the lisp terms) for the base object type is
  13. a very bad one.  First, there can be no general, useful, ordering between
  14. different types of objects.  Keith pointed this out in his response.  John,
  15. your 2nd response, where you indicated that ordering, even arbitrary, could be
  16. useful for lists is partially correct in that the list implementation may use
  17. ordering to be more efficient.  If the objects have no specified ordering, that
  18. is, if the definition of the object does not have an ordering property, then
  19. ANY ordering is arbitrary.  If the implementation of the list wants an
  20. arbitrary ordering, IT CAN IMPOSE IT!  It is a property of the LIST to have
  21. that ordering, not the objects it contains.  Therefore, the implementation that
  22. defines the ordering should contain the code to do the ordering.
  23.     The ordering that is specified in Alan's first link is as easily imposed
  24. by the list as the object (and doesn't violate encapsulation, either).
  25.     If you have classes which have the property of being ordered, it should be
  26. defined for those classes, and only type-safe comparisons between these classes
  27. should be allowed.
  28.     So, keep TObject clean.  Leave ordering to those objects who have it as an
  29. intrisic property.
  30. --Hugh Hoover
  31.   Xanadu Operating Company
  32.  
  33. p.s.  John, re: your item 4 ... Object Pascal has no multiple-inheritence ...
  34.     This is a significant ASSET for Object Pascal, in that multiple inheritence
  35. is NEVER required, and just complicates the language.  But that's another
  36. argument :-}.  Keep the language simple!
  37.  
  38.  
  39.